JavaScript is a very forgiving language. It’s easy to write code that runs but has issues in it.
In this article, we’ll look at how to handle errors in JavaScript programs.
Design Implications of Error Processing
If we handle errors in our system, then we got to test our error processing code.
This is to ensure that we did everything properly.
If we have return values, then we test the return values.
We should never ignore error information.
If we have a consistent approach for handling errors, then we should follow it so that we can have issues with inconsistency and duplication of error processing code.
Exceptions
Exceptions are the means of which code can pass along errors from the code that caused the error to the surface.
If we don’t want our program to crash, then we should catch them so that we can deal with them gracefully.
In JavaScript, we can throw errors by using the throw keyword on the Error class or subclass of Error .
To catch errors, we can use try...catch to catch them.
If we want to run code regardless of whether an exception is thrown, we can put them in the finally clause.
For instance, we can write the following to throw an error:
throw new Error('error');
To catch exceptions that are raised from code that may cause errors, we write:
try {
errorThrowingCode();
//...
} catch (ex) {
// handdle errors
}
Where errorThrowingCode may throw errors.
A finally clause may be added after the catch block.
Use Exceptions to Notify Other Parts of the Program About Errors that Should not Be Ignored
The whole point of throwing exceptions is that we can’t ignore them without users seeing them.
Therefore, we should use exceptions to notify other parts of our programs about errors that shouldn’t be ignored.
Throw an Exception Only for Conditions that are Truly Exceptional
Even though we should throw exceptions for things that shouldn’t be ignored, we shouldn’t use them everywhere.
If we have too many then, then we’ve to have code everywhere to handle exceptions.
We don’t want that, so we should think about using exceptions for those errors that must be handled for proper operations of our program.
Exception handling makes our code more complex as we have to catch them and then handle them.
There’re better ways to deal with non-critical errors like checking for values and do something instead of throwing exceptions.
Don’t Use an Exception to Pass the Buck
If errors can be handled locally, then we should do that.
Handling them elsewhere just makes our code more complex.
Include in the Exception Message All Information that Led to the Exception
We should include useful information in our exceptions so that we can have enough information to debug and fix the issue that caused the exception to be raised.
It just makes dealing with errors easier if we give everyone more information so that we can deal with them.
Avoid Empty Catch Blocks
Empty catch blocks are useless, so we shouldn’t include them.
We got to handle exceptions that are thrown rather than doing nothing when an exception is caught.
If we want to do nothing, we should at least log about the error.
Know the Exceptions Our Library Code Throws
Knowing exceptions that our libraries throw is important so that we can handle them when they arise.
Failing to catch them will be caught our program to crash and that won’t be good user experience.
Consider Building a Centralized Exception Reporter
Creating a centralized exception reporter makes logging and formatting exceptions a breeze as all that is done in one place.
It’s better than handling them all separately in different places.
Standardize Our Project’s Use of Exceptions
For the sake of keeping things consistent, we should standardize how exceptions are handled in our code to reduce developers’ cognitive load.
We can create project-specific exception classes and define code that is allowed to throw exceptions.
Also, we can centralize reporting and logging.
Conclusion
There is a lot to think about when we throw exceptions.
We got to think about when and how to throw exceptions. Where they handle and whether we can create our own error classes.
Standardization would make our work easier.
